• Remove repository restriction to enable Docker builds for forks
• Update Maven and JDK versions in Dockerfiles
• Add explicit module-info.java file copies to Docker build context
• Separate Docker build commands into individual RUN layers

Enable Docker builds for repository forks

• Removed if: github.repository == 'JabRef/jabref' condition from build job
• This allows Docker image builds to run on forked repositories

.github/workflows/dockerimages.yml

Update versions and fix module-info copying

• Updated Maven base image from 3.9.12 to 3.9.14
• Updated commented JDK alternative from 25 to 26
• Added explicit COPY commands for all module-info.java files from each component
• Separated build, dist directory creation, and artifact movement into individual RUN layers

Dockerfile.jabkit

Update versions and fix module-info copying

• Updated Maven base image from 3.9.12 to 3.9.14
• Updated commented JDK alternative from 25 to 26
• Added explicit COPY commands for all module-info.java files from each component
• Separated build, dist directory creation, and artifact movement into individual RUN layers

Dockerfile.jabsrv

Description

A commented-out FROM ... AS build line is kept in a modified section of the Dockerfile, which is
considered commented-out code. This increases maintenance noise and violates the requirement to
remove commented-out code in touched areas.

Code

Dockerfile.jabkit[4]

+# FROM amazoncorretto:26-jdk AS build

Evidence

PR Compliance ID 10 requires removing commented-out code in modified areas; the PR changes and
retains a commented-out FROM instruction in Dockerfile.jabkit.

AGENTS.md
Dockerfile.jabkit[4-4]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A commented-out Docker instruction (`# FROM ...`) remains in a modified part of the Dockerfile.
## Issue Context
The project compliance rules require removing commented-out code in touched sections.
## Fix Focus Areas
- Dockerfile.jabkit[4-4]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

After removing the job-level repository guard, the workflow runs in forks but still generates tags
for ghcr.io/JabRef/... and labels pointing to https://github.com/JabRef/jabref, so fork builds
produce incorrect image metadata and cannot publish correctly-namespaced images on fork push/tag
events.

Code

.github/workflows/dockerimages.yml[25]

-    if: github.repository == 'JabRef/jabref'

Evidence

The PR removes the only job-level condition that prevented this workflow from running outside the
upstream repo. In the resulting workflow, docker/metadata-action still hard-codes the GHCR
namespace to JabRef and hard-codes the source label to the upstream repo URL, so any run in a fork
will produce upstream-branded tags/labels rather than fork-specific ones.

.github/workflows/dockerimages.yml[3-14]
.github/workflows/dockerimages.yml[23-29]
.github/workflows/dockerimages.yml[31-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Docker Images workflow now runs in forks (job-level guard removed), but still hard-codes the upstream GHCR namespace (`ghcr.io/JabRef/...`) and upstream `org.opencontainers.image.source` label. This causes fork builds to generate incorrect tags/labels and prevents forks from producing correctly-namespaced images on fork `push`/`tag` events.
### Issue Context
The workflow already gates login/push to upstream-only, but the metadata generation is still upstream-specific.
### Fix Focus Areas
- .github/workflows/dockerimages.yml[31-45]
- Change `images:` to use the current repo owner dynamically (e.g., `ghcr.io/${{ github.repository_owner }}/${{ matrix.component }}`).
- Change `org.opencontainers.image.source` to use the current repo (e.g., `https://github.com/${{ github.repository }}`).
- .github/workflows/dockerimages.yml[46-88]
- Revisit login/push gating if the intent is to allow forks to publish on their own `push`/`tag` events (otherwise keep upstream-only, but ensure tags/labels are still fork-correct for non-push builds).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The PR introduces an identical block of COPY .../module-info.java lines in multiple Dockerfiles,
duplicating build logic. This increases maintenance overhead and risk of divergence when module
paths change.

Code

Dockerfile.jabkit[R35-42]

+COPY ./jabgui/src/main/java/module-info.java ./jabgui/src/main/java/module-info.java
+COPY ./jabkit/src/main/java/module-info.java ./jabkit/src/main/java/module-info.java
+COPY ./jablib/src/main/java/module-info.java ./jablib/src/main/java/module-info.java
+COPY ./jabls/src/main/java/module-info.java ./jabls/src/main/java/module-info.java
+COPY ./jabls-cli/src/main/java/module-info.java ./jabls-cli/src/main/java/module-info.java
+COPY ./jabsrv/src/main/java/module-info.java ./jabsrv/src/main/java/module-info.java
+COPY ./jabsrv-cli/src/main/java/module-info.java ./jabsrv-cli/src/main/java/module-info.java
+COPY ./test-support/src/main/java/module-info.java ./test-support/src/main/java/module-info.java

Evidence

PR Compliance ID 32 requires refactoring duplicated logic into shared helpers/workflow steps; the
same module-info.java COPY block is added in both Dockerfile.jabkit and Dockerfile.jabsrv.

Dockerfile.jabkit[35-42]
Dockerfile.jabsrv[35-42]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR adds the same `COPY .../module-info.java` list to multiple Dockerfiles, duplicating logic.
## Issue Context
Keeping duplicated Dockerfile logic in sync is error-prone when modules are added/renamed. Consider consolidating the shared build pre-copy logic into a single reusable approach (e.g., a shared base build stage/image, a single parameterized Dockerfile with `--build-arg`/`--target`, or another consolidation pattern acceptable for the repo).
## Fix Focus Areas
- Dockerfile.jabkit[35-42]
- Dockerfile.jabsrv[35-42]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools